敏捷開發的本質是透過短週期的迭代產生成果，再透過反覆修正能解決傳統開發方法上，傾向「梭哈」不夠彈性的問題。而這每一次的迭代，其他的敏捷方法有的叫 Iteration ，在 Scrum 裡，則叫做 Sprint (衝剌)。

Scrum 中並沒有規定一個 Sprint 時間多長，但為了能足夠有彈性地對變化做出回應，通常不會超過四個禮拜。一個禮拜太短，容易有空轉的問題（參考這篇 Context Switch），四個禮拜對於現今競爭激烈需快速反應的商業環境又有點太久。所以一個 Sprint 設定在二到三個禮拜相對而言較為普遍。

接著，會以大的項目走一遍，帶大家了解 Scrum 框架的整體運作過程。

產品待辦清單（Product Backlog）

首先一開始，產品負責人經過從市場端發現的洞見，以及與利害關係人討論溝通後，手上會持有一些這個專案想做的功能，他會將它們依商業價值排序好，成為產品清單（Product Backlog）。

衝剌規劃（Sprint Planning）

第二步，PO 找開發團隊以及 Scrum master 召開 Sprint Planning，這個會議要討論的東西包含了三件事－做什麼、怎麼做、誰來做：

1. 做什麼－PO 向團隊說明 backlog，團隊選擇幾組 backlog 裡的 Story 做為該次 Sprint 交付的承諾，放進下個階段會用到的衝剌清單（Sprint Backlog）中。
2. 怎麼做－開發團隊討論如何才能交付這些承諾的 Story，拆解成實際的任務工項。
3. 誰來做－拆解成任務工項後，對每個工項進行估點和任務分配。

你可能會擔心拆解任務時可能不小心會漏估，別太擔心，這些都將會是日後團隊學習的機會。實際工作開始展開後，當發現有工項少估時，此時再把新項目加進 Sprint backlog 中就好。每次的失誤，都會是團隊下次吸收經驗、成長的開始。一般來說，高效率的開發團隊能夠在 Sprint Planning 會議上，確認好 70%－80% 的工作。

開發衝剌（Sprint）

第三步，開發團隊開始進入開發，在這段期間，除了開發外，還有二件重要的事

1. PO 及 Scrum Master 保護住這段時間盒：PO 雖代表業務方，但需要承諾，在這個 Sprint 中，不再追加其他額外的 Story ，除非開發團隊進度超前，主動要求。
2. 每日小而短的同步與溝通：Scrum Master 帶領開發團隊的成員，每天於固定時間、地點，進行站立會議（Daily Stand-up），Scrum Master 負責協調與移除導致開發團隊「慢」下來的原因。

補充說明，團隊於該次 Sprint 所開發出來可用的成果，叫做產品增量（Increment）。產品增量是每次取得回饋時重要的依據，Scrum 一個重要的精神就是：再多的系統描述與說明，不如一個可實際操作的軟體。

衝剌審視會議（Sprint Review）

第四步，當該次 Sprint 的開發到了尾聲，Scrum Master 會安排一場 Sprint Review Meeting （衝剌審視會議），向產品負責人及利害關係人們展示這次 Sprint 的增量成果，在這個會議上，取得大家的意見回饋，以便進行下個 Sprint 的迭代。

回顧自省會議（Retrospective Meeting）

最後，為了持續的讓團隊能夠自我學習以及提升幸褔感，Scrum Master 也會在 Review Meeting 後，安排一場 Retrospective Meeting（回顧自省會議）。這個會議是專門留給團隊的時間，讓夥伴們可以專注討論對於當次 Sprint 的體會，做的好的地方以及還能加強的地方。每次的需改善處只要讓團隊選擇最有感的 1-2 項即可，擬定改善方式後，於下個 Sprint 中進行實踐，並且待下次的 Retro 會議，看看是否有所改善。

一般而言，一個從未接觸過敏捷的團隊要掌握敏捷流程的精髓，大概需要經過 6 個 Sprint，這無關一個 Sprint 是幾週，所以在一個傳統組織想要開始導入 Scrum 時，我們往往會推薦從二週的 Sprint 開始，如此既避免了 Context Switch 問題，也能有助團隊學習適應 Scrum 的快節奏步調。